The block diagram shown in FIG. 2 depicts an alternative billing 
verification system 200 according to another presently preferred embodiment 
of the invention. The billing verification system 200 depicted in FIG. 2 
provides billing verification services to a number of different customers 102. 
In this way, the billing verification system 200 of FIG. 2 may act as an 
industry-wide clearinghouse for billing exceptions. The billing verification 
system 200 itself may be controlled and operated by a customer 102 or by a 
third-party service provider. 

Operation of this billing verification system 200 is similar to that of the 
system 100 shown in FIG. 1. Billing data is uploaded to the database 108 
either by a customer 102 or a vendor 104. The customer 102 then accesses 
the billing verification system 200 via a distributed computer network 118, 
such as the Internet. The customer 102 then reviews the billing data, and 
generates any necessary billing exception records through use of the 
customer graphical user interface. The vendor 104 also accesses the billing 
verification system 200 via the distributed computer network to review the 
billing exception records via the vendor graphical user interface. As described 
above, the authentication and access control procedure restricts customer 
and vendor access to only the billing data that relates to that customer 102 or 
vendor 104. Again, multiple employees of both the customers 102 and the 
vendors 104, perhaps in remote locations, may access the billing verification 
system through workstations connected to the server 106 via the Internet. 

Operation of these billing verification systems 100, 200 will now be 
described with reference to FIGS. 3-13. Unless otherwise noted, the 
discussion will be applicable to both the billing verification system 100 of 
FIG. 1 and the billing verification system 200 of FIG. 2. 

The flowchart shown in FIG. 3 illustrates a method of verifying charges 
billed by a vendor 104 to a customer 102 according to one preferred 
embodiment of the invention. The following description of the method refers 
generally to customers 102 and vendors 104. Because the method is 
applicable to a wide variety of industries, the vendors 104 may represent 
parties that provide any of number of different products or services to the 
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customers 102. The method involves a billing verification system 100, 200, as 
described above. For purposes of this method, the billing verification system 
100, 200 may be controlled and operated by a customer 102, a vendor 104, or 
a third-party. 

First, the billing data is loaded into the billing verification system 100, 
200 in step 302. Depending on the format in which the billing data is provided 
by the vendor 104, the data may be loaded automatically from an electronic 
bill file or it may be entered manually from a hardcopy bill. Except in the case 
of the transition system described above, the billing data resides in the 
database 108 once it is loaded. The customer then accesses the database 
108 and reviews the billing data to identify any billing exceptions in step 304. 
Customer review of the billing data in step 304 may be performed manually by 
a customer audit representative, automatically by a computerized auditing 
system, or by a combination of both manual and automatic review. In 
addition, multiple customer employees, such as field representatives in 
remote locations, may access the billing verification system 100, 200 to 
review the billing data. In step 306, for each billing exception identified by the 
customer, the billing verification system 100, 200 generates a billing exception 
record in the database 108. The billing exception record may contain 
information identifying the bill to which an exception is taken, the amount of 
the exception, and the reasons justifying the exception. The vendor 104 is 
then notified of the customer's billing exceptions in step 308. Preferably, this 
notification is via an electronic mail message generated by the billing 
verification system 100, 200 and sent to the vendor 104. 

The vendor 104 then accesses the database 108 and reviews the 
billing exception records in step 310 to identify acceptable billing exceptions. 
Like the customer review, vendor review may include review by a number of 
vendor employees, such as field representatives in remote locations. The 
vendor may approve, disapprove, or partially approve each billing exception. 
In each case, the billing verification system 100, 200 generates a billing 
exception response record in the database 108. The billing exception 
response record may contain information indicating whether the exception has 



been approved or disapproved, as well as a reason for the approval or 
disapproval. If the exception is partially approved, the billing exception 
response record also may include the partially approved dollar value. The 
billing verification system 100, 200 then notifies the customer of the vendor's 
billing exception responses in step 314. Like the vendor notification, customer 
notification preferably is via an electronic mail message generated by the 
billing verification system 100, 200 and sent to the customer. 

In another preferred embodiment of the present invention, the billing 
verification system 100, 200 is used in the specific industry of railcar repair. In 
this embodiment, the billing verification system 100, 200 is used to process 
billing exceptions for railcar repair charges billed by a repair agent to a railcar 
equipment owner. The repair agent serves as a vendor 104 of repair services 
to its customer 102, the railcar owner. This embodiment of the invention, as 
viewed from the railcar owner's perspective, will now be discussed with 
reference to FIGS. 4-8. 

The flow diagram shown in FIG. 4 illustrates a transition method of 
verifying repair charges using both a mainframe accounting system 116 and 
the billing verification system 100, as described above with reference to 
FiG. 1. The method begins with the step 402 of loading billing data from 
billing repair cards into the mainframe accounting system 116. Repair agents 
provide billing data to railcar owners in the form of billing repair cards. A 
billing repair card indicates, among other things, the railcar number, the kind 
of car, the repair date and location, and description and cost of the necessary 
parts and labor. The format of billing repair cards is governed by the AAR 
Interchange Rules. 

As described above, the billing data may be loaded into the mainframe 
accounting system 116 in a number of ways. If the billing repair cards are 
provided in hardcopy format, the railcar owner may manually enter the billing 
data via a data entry interface. If the billing repair cards are provided in an 
electronic file, the billing data may be uploaded to the system automatically. 

After the billing data is loaded into the mainframe accounting system 
116, the railcar owner reviews the billing data for any incorrect, or disputed, 



